Среди открытых документов VMware появился очень интересный док - "vSphere Snapshots: Performance and Best Practices", в котором рассматривается весьма полезные многим администраторам аспекты - производительность снапшотов, а также, как правильно с ними обращаться. Мы часто пишем про это (1, 2, 3), а вот теперь есть и хороший документ с картинками.

Основные темы документа:

• Что такое снапшоты
• Какие есть форматы снапшотов
• Описание тестового окружения и рабочих нагрузок
• Результаты тестирования производительности
• Выводы по этим результатам

Итак, для тестирования использовались следующие рабочие нагрузки:

• FIO (стандартный тест производительности ввода-вывода)
• JVM (бенчмарк SPECjbb 2015)
• OLTP database (тест HammerDB)

Давайте взглянем на результаты тестирования производительности с точки зрения гостевой системы и ее приложений:

1. Число выдаваемых IOPS в зависимости от количества снапшотов для виртуальной машины (Random I/O):

В этом тесте и в последующих мы увидим, что снапшоты не влияют на производительность хранилищ VVols - такова природа этих хранилищ. А вот с VMFS и vSAN мы видим, что производительность падает, для VMFS - в три раза уже с первого снапшота, для vSAN - с третьего.

2. Для последовательного чтения vSAN ведет себя значительно лучше, а вот на VMFS производительность уже с первого снапшота падает в 2.5 раза, и дальше только хуже:

3. Для обработки запросов SPECjbb во всех трех случаях снапшоты не оказывали влияния на производительность:

4. По количеству транзакций в секунду тест HammerDB тоже показывает падение производительности хотя бы с одним снапшотом почти в 3 раза:

Интересно, что для хранилищ vSAN со снапшотами просадки по производительности для теста HammerDB нет.

5. Интересна также производительность гостевых ОС при соазднии и при удалении снапшотов:

Как мы видим, на VMFS критичен первый снапшот, и исходная производительность возвращается виртуальной машине только с удалением последнего снапшота. На vSAN производительность уменьшается и увеличивается постепенно, с изменением количества снапшотов.

Для больших блоков ввода вывода страдает только VMFS при последовательном чтении:

При последовательной записи больших блоков снапшоты влияют только на VMFS (при этом, только первый):

Ну и в заключение VMware приводит такую табличку потерь производительности для виртуальных машин с одним снапшотом:

Итак, очевидные выводы:

• Снапшоты - зло. Особенно для VMFS и иногда для vSAN.
• Особенное зло снапшотов проявляется для случайного чтения (Random reads), хотя и для последовательного все далеко не так хорошо.
• Хранилищам VVol все равно на снапшоты, производительность не падает.
• Зло, как правило, именно первый снапшот, дальше уже не так важно, сколько их, но производительность продолжает падать.
• При удалении снапшотов производительность ВМ возвращается к исходному уровню.

На сайте проекта VMware Labs обновилась утилита HCIBench 2.6, которая до этого обновлялась осенью прошлого года. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ VMware vSAN, а также других конфигураций виртуальной инфраструктуры. О прошлой версии HCIBench 2.4 мы писали вот тут.

Суть работы HCIbench проста - пользователь задает параметры работы скрипта, а утилита дает команду средству Vdbench, содержащую инструкции о том, какие действия необходимо выполнить в кластере хранилищ. Это может вам пригодиться, например, когда вы хотите убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.

Давайте взглянем на новые возможности HCIBench 2.6:

• Сервер tomcat обновлен до версии 8.5.68
• Поддержка IPv6 для сетей ВМ и Management Network - как для DHCPv6, так и для link-local mode
• Поддержка режима развертывания multi-writer disk
• Улучшенная пре-валидация за счет перехода на govc
• Поддержка спецификации read/write io_limit для fio
• Исправлена ошибка при запуске в инфраструктуре VMC
• Улучшена система сбора диагностических бандлов в режиме отладки vSAN

Скачать VMware HCIBench 2.6 можно по этой ссылке.

На сайте проекта VMware Labs появилась новая утилита - Edge Services Observability. Она предназначена для мониторинга служб Edge Services (VMware Tunnel, Content Gateway, Secure Email Gateway, Reverse и Horizon Secure Access), которые запущены на модуле Unified Access Gateway - одном из ключевых компонентов решений VMware Horizon и Workspace ONE.

С помощью этого средства можно понять:

• Производительность шлюза на основе его загрузки
• Распределение трафика
• Влияние правил Device Traffic Rules на производительность

Основные возможности утилиты:

• Поставляется как готовый к настройке и развертыванию виртуальный модуль (Virtual Appliance) в формате OVA:

• Веб-портал для управления инстансами Unified Access Gateway (UAG):

• Дашборды для визуализации метрик компонентов VMware Tunnel и VMware Horizon на базе Grafana:

• Возможность настройки алертов на основе различных условий, что позволяет оперативно выявлять аномалии

Скачать VMware Edge Services Observability можно по этой ссылке. Более подробная информация о продукте доступна тут.

На днях компания VMware обновила свое основное средство для автоматизации рутинных операций в облаке на базе vSphere, выпустив vRealize Automation 8.4.2. Несмотря на то, что это минорный релиз, в продукте появилось довольно много всего нового. В прошлый раз о vRA мы писали вот тут.

Давайте посмотрим на новые возможности VMware vRA 8.4.2:

• Диски, добавленные через vRealize Orchestrator, и расширения теперь показываются в диаграмме развертывания (топология)
• Возможности шифрования Microsoft Azure disk encryption, которые поддерживают:
  • Disk Encryption для independent managed disks
  • Disk Encryption для действия Add Disk (Day 2 action)
• Группы Property groups теперь могут:
  • Использовать рабочие процессы vRO для задания свойств внешних динамических значений
  • Привязывать пароли к property groups для использования разных паролей для разных групп
• Теперь можно назначить одинаковые диапазоны IP-адресов, которые приходят от внутреннего или внешнего IPAM, для разных сетей
• События Provider Events срабатывают, когда тенант вызывает одно из действий CRUD (Create, Read, Update, and Delete)
• Настраиваемый лимит max number of supervisor namespaces, который определяет максимальное число пространств имен для проекта в заданной зоне Kubernetes
• Управление снапшотами Microsoft Azure disk snapshot management теперь поддерживает:
  • Выявление снапшотов
  • Действие по удалению снапшота (Day 2 action)
  • Совместимость Managed Disk Snapshot – поддержка параметров Resource Group, Encryption set, Network policy и Tags

Более подробно о новых возможностях и изменениях в API решения VMware vRealize Automation 8.4.2 можно прочитать в Release Notes. Скачать vRA можно по этой ссылке.

На сайте проекта VMware Labs вышло большое обновление утилиты VMware OS Optimization Tool версии v2106.

Напомним, что это средство предназначено для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач. О прошлом ее обновлении мы писали вот тут.

Во-первых, весь код утилиты был полностью портирован для использования в производственном окружении и переписан в соответствии со стандартами VMware. Во-вторых, теперь версия v2106 соответствует году и месяцу релиза, чтобы полностью соответствовать правилам версионирования VMware Horizon.

Давайте посмотрим, что нового есть в этой утилите:

1. Пользовательский интерфейс

Теперь в качестве графического фреймворка используется Clarity, который стал стандартом для консолей различных продуктов VMware. Он использует темную тему, также обновился логотип.

Экран Optimize был приведен в порядок, также элементы слева мигрировали на главную панель. Был улучшен блок системной информации, ну и был полностью переработан Analysis Summary Graph.

2. Оптимизации

Теперь в утилите есть встроенный шаблон оптимизаций версии 2.0, в котором произошли следующие изменения:

• Удалено много неактуальных элементов (например, они не изменяли дефолтные настройки Windows)
• Некоторые элементы отключали функциональность Windows, которая могла понадобиться, поэтому их тоже убрали
• Некоторые оптимизации изменяли UX/UI, но не давали существенного прироста производительности - их тоже стало меньше (но их все равно можно сделать через групповые политики или политики Dynamic Environment Manager)

Для получения полного списка изменений в шаблоне обратитесь к этой статье.

Также были переработаны заголовки оптимизаций, чтобы лучше понимать их суть. Кроме того, они теперь более логично сгруппированы. В шаблоне теперь новый синтаксис для управления представлениями групп настроек.

Все оптимизации реестра теперь делаются через ветку HKCU, в которую копируется дефолтный профиль пользователя во время выполнения операции Optimize.

3. Плагин Microsoft Deployment Toolkit

Теперь с утилитой идет плагин для Microsoft Deployment Toolkit (MDT), который отдельно доступен для загрузки. Он позволяет использовать MDT для автоматизации создания золотых образов ОС и добавления кастомных задач, которые можно вставлять в последовательности задач MDT:

• Install Agents - здесь можно установить VMware Tools, Horizon Agent, Dynamic Environment Manager, App Volumes Agent.
• Run OS Optimization Tool tasks – это задачи из разделов Optimize, Generalize, Finalize.

Более подробно об использовании MDK и OS Optimization Tool написано тут. Также есть специальное руководство Using Automation to Create Optimized Windows Images for VMware Horizon VMs.

4. Прочие изменения

Теперь по умолчанию не отключены блоки функций Firewall, Antivirus и Security Center. Их можно отключить в разделе Common Options перед выполнением задачи Optimize. Тут важно учесть 2 момента:

• Публично загруженные шаблоны от пользователей не проверяются со стороны VMware
• Пользователи могут создавать собственные шаблоны и экспортировать/импортировать их в формате XML

Функция и вкладка Remote Analysis был удалена из утилиты, также теперь недоступны утилиты NSUDO и SetAcl, на смену которых пришла внутренняя функциональность.

Помимо перечисленного, в утилите VMware OS Optimization Tool было исправлено множество ошибок разной степени критичности. Скачать VMware OSOT можно по этой ссылке. Основное руководство по использованию продукта доступно тут.

Это гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины в аренду по модели IaaS.

Активное развитие бизнеса и расширение его филиальной структуры неизбежно увеличивают расходы на поддержку сетевой инфраструктуры. Избежать лишних затрат, быстро подключать новые офисы и филиалы поможет Cloud SD-WAN от #cloudmts. Разбираемся, почему вам стоит задуматься о внедрении интеллектуального решения для организации территориально распределенной сети на базе технологий VMware уже сейчас.

Экономия на поддержке сетевой инфраструктуры

Cloud SD-WAN позволяет задействовать недорогие высокоскоростные интернет-каналы при сохранении требуемого качества обслуживания. Оборудование SD-WAN Edge обходится дешевле традиционных маршрутизаторов, а для подключения новых филиалов не требуется выезд высококвалифицированного специалиста.

Подключение новых офисов и филиалов за 5 минут

Чтобы добавить новый филиал в сеть, достаточно просто установить конечное устройство и подключить каналы связи. Оборудование активируется по ссылке из e-mail, где уже «зашиты» нужные параметры для настройки WAN-интерфейса оборудования.

Максимальное качество и высокая доступность

Технология DMPO обеспечивает высокое качество связи благодаря постоянному мониторингу состояния каналов связи по ключевым параметрам (Latency, Jitter, Packet Loss) и позволяет решению Cloud SD-WAN обеспечивать бесперебойную работу критичных приложений.

Безопасное использование нескольких подключений

Cloud SD-WAN позволяет использовать несколько каналов связи одновременно, а межсетевой экран на конечных устройствах подойдет для базовой защиты от сетевых угроз.

Бесплатный тест-драйв решения

Не уверены, что решение вам подойдет? С #cloudmts можно протестировать сервис бесплатно! Просто оставьте заявку и пользуйтесь Cloud SD-WAN 14 дней в рамках пробного периода.

Хотите познакомиться с магией SD-WAN лично? 6 июля в 11:00 ждем вас на вебинаре с экспертами #cloudmts и VMware! Обсудим обеспечение непрерывной связи между филиалами и ЦОД, подключение новых филиалов за 5 минут, сравним различные решения SD-WAN и поговорим о бесплатных возможностях для клиентов. Программа вебинара, детали и регистрация — на странице мероприятия!

Оригинал статьи в блоге ИТ-ГРАД.

На сайте проекта VMware Labs появилось обновление еще одной полезной штуки - Horizon Peripherals Intelligence 2.0. О первой версии этого средства мы писали осенью прошлого года вот тут, напомним, что оно предназначено для самодиагностики периферийных устройств пользователями решения VMware Horizon. C помощью данного средства можно проверить работоспособность и поддержку устройств как со стороны конечных пользователей, так и администраторов платформы Horizon.

Напомним, что утилита Horizon Peripherals Intelligence служит для решения следующих задач:

• Публикация отчета о диагностике устройств по запросу конечных пользователей
• Обслуживание спектра пользовательских устройств в рамках поддерживаемых со стороны официального списка совместимости device compatibility matrix
• Возможность получения администратором доступа к метаданным устройств в каждой категории, где он может загружать, изменять и удалять метаданные, таким образом обслуживая матрицу поддерживаемых устройств на машинах пользователей

Что нового появилось в версии 2.0:

• Добавлена поддержа клиентов Linux на базе Ubuntu 18.04 , 20.04 и Redhat 8.3, 8.4
• Добавлена поддержка смарт-карт, USB-мыши и клавиатуры для Windows-клиентов
• Добавлена поддержка USB-дисков, сканнеров, принтеров, камер, USB-мыши и клавиатуры для Linux-клиентов
• Добавлена поддержка агента Horizon agent для последних версий Windows 10 21H1 и Windows Server 2022
• Обновлена таблица Device Matrix - теперь она соответствует разделу VMware validated peripherals на VMware Marketplace

Скачать Horizon Peripherals Intelligence 2.0 можно по этой ссылке.

Многие сетевые администраторы используют решение VMware vRealize Network Insight (vRNI), предназначенное для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в виртуальном датацентре. Также в средних и крупных компаниях для управления тикетами используется ITSM-система ServiceNow, которая, помимо прочего, позволяет управлять инцидентами различного характера в ИТ-инфраструктуре, в том числе, виртуальной.

Сегодня мы посмотрим, как можно интегрировать эти решения через почту, чтобы администраторы получали оповещения об инцидентах в сфере сетевой безопасности в консоли ServiceNow. Для vRNI вам понадобится административный доступ, а для ServiceNow - права для создания инцидентов и входящих действий (inbound actions).

Сначала вам потребуется найти системный email-адрес ServiceNow. Например, для облачного продукта ServiceNow Cloud это адрес instancename@serive-now.com. Посмотреть данный адрес можно в разделе System Mailboxes -> Administration -> Email Accounts -> ServiceNow SMTP:

Затем в консоли vRNI нужно настроить отсылку почтовых нотификаций в ServiceNow для нужных алертов. Для этого идем в Settings -> Alerts and Notification -> Alerts:

Открываем нужный алерт, выставляем частоту отсылки сообщений и выбиваем почтовый адрес ServiceNow:

Теперь нужно создать Inbound Action для создания инцидента в ServiceNow. Идем в ServiceNow -> System Policy -> Email -> Inbound Actions -> New:

Там задаем имя инцидента, целевую таблицу и тип действия Record Action:

На вкладке Action нужно создать кастомный скрипт для обработки и кастомизации полей полученного сообщения:

Вот пример такого скрипта:

current.caller_id = gs.getUserID();
current.comments = "received from: " + email.origemail;
current.short_description = email.subject;
current.description = email.body_text.toString();
current.category = "network";
current.incident_state = IncidentState.NEW;
current.notify = 2;
current.contact_type = "email";
if (email.body_text.toString().indexOf('Critical') >=0 ){
 current.impact=1;
 current.urgency=1;
}
else if (email.body_text.toString().indexOf('Info')>=0 ){
 current.impact=2;
 current.urgency=3;
}
else if (email.body_text.toString().indexOf('Moderate')>=0 ){
 current.impact=2;
 current.urgency=2;
}
else if (email.body_text.toString().indexOf('Warning')>=0 ){
 current.impact=1;
 current.urgency=2;
}
if (email.body.assign != undefined)
 current.assigned_to = email.body.assign;
current.insert();

В этом скрипте можно задать параметры фиксируемого инцидента, такие как его критичность, срочность и т.п. Также вы можете написать свой сценарий на базе документации к ServiceNow. Инциденты будут отображаться в разделе Incident -> All.

Источник.

Это гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины в аренду по модели IaaS.

В декабре прошлого года компания Red Hat официально заявила о досрочном прекращении поддержки популярного дистрибутива Linux, CentOS, — на восемь лет раньше запланированного. Дистрибутив должен был «прожить» до 2029-го, однако его перестанут поддерживать уже в конце этого года. А значит, пользователи CentOS перестанут получать обновления, включая исправление ошибок в ядре и ПО.

Эта новость крайне взбудоражила ИТ-сообщество. Чтобы как-то сгладить негативную реакцию, Red Hat даже предложила пользователям перейти на CentOS Stream. Технолосфера отреагировала на это событие по-своему — участники рынка open source ПО поспешили предложить юзерам собственные альтернативы «брошенной» CentOS:

• Almalinux — разработка компании Cloudlinux, первый релиз которой состоялся в марте этого года.
• «Отец» CentOS Грег Курцер тоже не остался в стороне и заявил о создании Rocky Linux. Позже стало известно, что Курцер даже создал стартап Ctrl IQ — планируется, что он и будет спонсировать проект и ПО.
• ИТ-гигант Oracle, который более 10 лет занимается развитием Oracle Linux, выпустила бесплатную утилиту для сисадминов, который позволяет бесшовно переехать с CentOS на версию от Oracle.

Теперь в новостях о CentOS отметилась и американская Virtuozzo, специализирующаяся на разработке ПО для виртуализации. Компания предоставила всем желающим бесплатный доступ к VzLinux 8. Представители компании сообщают, что их разработка может полностью заменить CentOS 8 и полностью совместима с RHEL.

VzLinux — это серверный дистрибутив ОС, который можно запускать как на физических машинах и ВМ, так и в контейнерах. Вдобавок разработчики предоставляют пользователям утилиту для безболезненной миграции на собственный дистрибутив.

Оригинал статьи в блоге ИТ-ГРАД.

Компания VMware заявила о доступности решения VMware NSX Advanced Firewall for VMware Cloud on AWS, предназначенного для защиты сетевых соединений организаций, использующий публичное облако VMware Cloud на базе инфраструктуры AWS SDDC (software-defined data center). С помощью этого фаервола администраторы смогут контролировать все коммуникации на уровне 7, используя DPI-техники анализа пакетов на всех виртуальных сетевых адаптерах vNICS виртуальных машин на хостах ESXi виртуального датацентра SDDC.

Используя NSX Advanced Firewall for VMConAWS, вы получите следующие возможности:

• Обнаружение попыток использования эксплоитов и уязвимостей в вашей инфраструктуре
• Защита от уязвимостей на базе гранулярных политик безопасности, работающих на уровне приложений
• Уменьшение поверхности атаки для ваших рабочих нагрузкой за счет регулирования только разрешенного трафика приложений в вашем датацентре
• Бесшовный анализ всего трафика датацентра без единой точки анализа, которая могла бы вызвать падение сетевой производительности
• Возможности для обеспечения соответствия отраслевым стандартам (compliance)

NSX Advanced Firewall можно купить как аддон к вашей инфраструктуре VMware Cloud on AWS. Подробнее об этом фаерволе вы можете прочитать в блоге VMware.

Не все администраторы VMware vSphere знают, что у VMware есть очень полезный ресурс Ports and Protocols, где можно посмотреть актуальные порты и протоколы, которые используются различными продуктами. Мы писали об этом сайте в 2019 году, с тех пор он существенно обновился, и теперь там есть информация по портам и соединениям практически для всех продуктов.

Во-первых, в колонке слева теперь доступна информация не по 12 продуктам, как раньше, а по 34, среди которых есть и относительно новые, такие как Tanzu Kubernetes Grid и Lifecycle Manager:

Во-вторых, в верхней части страницы появилась вкладка «Network Diagrams», где собраны несколько сетевых диаграмм, наглядно показывающих соединения между различными компонентами продуктов:

Пока таких диаграмм немного, но список решений будет пополняться.

Компания VMware анонсировала обновление решения VMware HCX 4.1, предназначенного для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на платформе VMware vCloud. Напомним, что о версии HCX 4.0 мы писали весной этого года вот тут.

Давайте посмотрим, что нового в HCX 4.1:

1. Предиктивные оценки для пакетных миграций

В версии 4.0 появилась оценка пакетных миграций (Bulk Migrations), а в версии 4.1 появился драфтинг процесса оценки пакетных миграций, что позволяет быстро сделать прикидку по времени переноса ВМ:

2. Seed Checkpoint для пакетных миграций

Раньше при пакетной миграции больших виртуальных машин на базе репликации в случае неудачной миграции происходило уничтожение данных реплик на целевой площадке, что могло привести к потере данных состояний миграции за несколько дней. Теперь же можно создать контрольные точки репликации, которые можно повторно использовать в случае неудачного завершения миграции. Включается это в Migration Wizard:

3. Финальная доступность Mobility Optimized Networking (MON)

Эта возможность позволяет включать маршрутизацию трафика виртуальных машин, переносимых в онпремизное или публичное облако, через облачный шлюз, вместо использования маршрутизации через роутер на исходном сайте.

Это позволяет избежать hairpin-эффекта:

4. Увеличенные максимумы VMware HCX

Теперь лимиты максимальных конфигураций были увеличены еще больше:

Скачать VMware HCX 4.1 можно по этой ссылке, Release Notes доступны тут.

Как вы знаете, в кластере отказоустойчивости VMware HA есть Primary и Secondary хосты серверов ESXi. Первые отвечают за управление кластером и восстановление виртуальных машин, а вторые – только за исполнение операций и рестарт ВМ. Недавно мы, кстати, писали о том, как сделать хост VMware vSphere Primary (он же Master) в кластере HA, а сегодня расскажем о том, какие события происходят на этих хостах в случае отказа хоста (именно полного отказа, а не при недоступности, например, его в сети).

Как пишет Дункан Эппинг, если отказывает хост Secondary, то происходят следующие вещи, начиная с времени T0:

• T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
• T+3 секунды – хост Primary начинает отслеживать хартбиты на хранилище в течение 15 секунд
• T+10 секунд – хост помечается как unreachable и Primary хост начинает пинговать его Management Network (постоянно в течение 5 секунд)
• T+15 секунд – если на датасторе на настроены хартбиты, то хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин
• Либо если настроены хартбиты, но их нет, то через T+18 секунд хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин

В случае с отказом Primary хоста все немного дольше и сложнее, так как кластеру нужно определиться с новым Primary узлом и восстановить/перенастроить себя. Тут происходит следующее:

• T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
• T+10 секунд – начинаются выборы нового Primary хоста в кластере
• T+25 секунд - выбор хоста Primary сделан и он читает список виртуальных машин, а также ждет, пока Secondary хосты сообщат о своих виртуальных машинах
• T+35 секунд – старый хост Primary помечается как unreachable
• T+50 секунд – хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин согласно списку нового Primary

Надо помнить, что это все времена начала процессов, но не их завершения. Например, если процесс восстановления начинается через 15 секунд, то нужно время, чтобы найти место для виртуальной машины на новом хосте и запустить ее там – а вот это время рассчитать невозможно.

Многие администраторы VMware vSphere 7 после выхода обновления Update 2 этой платформы были удивлены, что многие настройки пропали из основного конфигурационного файла esx.conf. Мы уже рассказывали о configstore – хранилище настроек, к которому можно получить доступ через импорт и экспорт настроек в формате JSON.

Дункан Эппинг показал на примере виртуального коммутатора vSwitch, как можно работать с configstore и хранящимися там настройками. Например, вам требуется сменить имя виртуального коммутатора. Вы можете посмотреть его текущие сетевые настройки командой:

configstorecli config current get -c esx -g network_vss -k switches

Ну а экспортировать эти настройки в JSON-файл можно командой:

configstorecli config current get -c esx -g network_vss -k switches > vswitch.json

Далее вы просто открываете этот файл в текстовом редакторе и изменяете имя коммутатора c vSwitch0 на нужное:

Потом получившийся файл нужно обратно импортировать в configstore:

configstorecli config current set -c esx -g network_vss -k switches -i vswitch.json --overwrite

После этого вы увидите изменения в vSphere Client:

Также Дункан записал видео, в котором показан этот процесс:

После выхода VMware vSphere 7 Update 2 появилось много интересных статей о разного рода улучшениях, на фоне которых как-то потерялись нововведения, касающиеся работы с большими нагрузками машинного обучения на базе карт NVIDIA, которые были сделаны в обновлении платформы.

А сделано тут было 3 важных вещи:

• Пакет NVIDIA AI Enterprise Suite был сертифицирован для vSphere
• Появилась поддержка последних поколений GPU от NVIDIA на базе архитектуры Ampere  
• Добавились оптимизации в vSphere в плане коммуникации device-to-device на шине PCI, что дает преимущества в производительности для технологии NVIDIA GPUDirect RDMA

Давайте посмотрим на все это несколько подробнее:

1. NVIDIA AI Enterprise Suite сертифицирован для vSphere

Основная новость об этом находится в блоге NVIDIA. Сотрудничество двух компаний привело к тому, что комплект программного обеспечения для AI-аналитики и Data Science теперь сертифицирован для vSphere и оптимизирован для работы на этой платформе.

Оптимизации включают в себя не только средства разработки, но и развертывания и масштабирования, которые теперь удобно делать на виртуальной платформе. Все это привело к тому, что накладные расходы на виртуализацию у задач машинного обучения для карточек NVIDIA практически отсутствуют:

2. Поддержка последнего поколения NVIDIA GPU

Последнее поколение графических карт для ML-задач, Ampere Series A100 GPU от NVIDIA, имеет поддержку Multi-Instance GPU (MIG) и работает на платформе vSphere 7 Update 2.

Графический процессор NVIDIA A100 GPU, предназначенный для задач машинного обучения и самый мощный от NVIDIA на сегодняшний день в этой нише, теперь полностью поддерживается вместе с технологией MIG. Более детально об этом можно почитать вот тут. Также для этих карт поддерживается vMotion и DRS виртуальных машин.

Классический time-sliced vGPU подход подразумевает выполнение задач на всех ядрах GPU (они же streaming multiprocessors, SM), где происходит разделение задач по времени исполнения на базе алгоритмов fair-share, equal share или best effort (подробнее тут). Это не дает полной аппаратной изоляции и работает в рамках выделенной framebuffer memory конкретной виртуальной машины в соответствии с политикой.

При выборе профиля vGPU на хосте с карточкой A100 можно выбрать объем framebuffer memory (то есть памяти GPU) для виртуальной машины (это число в гигабайтах перед буквой c, в данном случае 5 ГБ):

Для режима MIG виртуальной машине выделяются определенные SM-процессоры, заданный объем framebuffer memory на самом GPU и выделяются отдельные пути коммуникации между ними (cross-bars, кэши и т.п.).

В таком режиме виртуальные машины оказываются полностью изолированы на уровне аппаратного обеспечения. Выбор профилей для MIG-режима выглядит так:

Первая цифра сразу после a100 - это число слайсов (slices), которые выделяются данной ВМ. Один слайс содержит 14 процессоров SM, которые будут использоваться только под эту нагрузку. Число доступных слайсов зависит от модели графической карты и числа ядер GPU на ней. По-сути, MIG - это настоящий параллелизм, а обычный режим работы - это все же последовательное выполнение задач из общей очереди.

Например, доступные 8 memory (framebuffers) слотов и 7 compute (slices) слотов с помощью профилей можно разбить в какой угодно комбинации по виртуальным машинам на хосте (необязательно разбивать на равные части):

3. Улучшения GPUDirect RDMA

Есть классы ML-задач, которые выходят за рамки одной графической карты, какой бы мощной она ни была - например, задачи распределенной тренировки (distributed training). В этом случае критически важной становится коммуникация между адаптерами на нескольких хостах по высокопроизводительному каналу RDMA.

Механизм прямой коммуникации через шину PCIe реализуется через Address Translation Service (ATS), который является частью стандарта PCIe и позволяет графической карточке напрямую отдавать данные в сеть, минуя CPU и память хоста, которые далее идут по высокоскоростному каналу GPUDirect RDMA. На стороне приемника все происходит полностью аналогичным образом. Это гораздо более производительно, чем стандартная схема сетевого обмена, об этом можно почитать вот тут.

Режим ATS включен по умолчанию. Для его работы карточки GPU и сетевой адаптер должны быть назначены одной ВМ. GPU должен быть в режиме Passthrough или vGPU (эта поддержка появилась только в vSphere 7 U2). Для сетевой карты должен быть настроен проброс функций SR-IOV к данной ВМ.

Более подробно обо всем этом вы можете прочитать на ресурсах VMware и NVIDIA.

На сайте проекта VMware Labs вышло очередное обновление - VMware ESXi Arm Edition версии 1.4. Напомним, что эта специальная версия версия гипервизора VMware предназначена для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). О версии 1.3 мы писали в начале апреля вот тут.

Давайте посмотрим, что нового в июньской версии VMware ESXi ARM Edition 1.4:

• Улучшенная технология виртуализации PMU (Performance Monitoring Unit)
• Исправлены проблемы с виртуальным устройством AHCI для некоторых ОС ACPI
• Улучшена работа с обработкой времени
• Экспериментальная поддержка NVIDIA Tegra Xavier AGX и NVIDIA Tegra Xavier NX (PCIe, USB, NVMe, SATA). Это что-то типа вот такой штуки:

• Экспериментальная поддержка серверов 2P Ampere на базе Altra. Это вот такие штуки:

• Увеличенная производительность виртуальных машин для мультисокетных серверов на базе ARM
• Исправлены проблемы с виртуальным NVMe в UEFI для некоторых ОС
• Улучшена виртуализация контроллера прерываний
• Улучшена общая производительность гипервизора и техник виртуализации в целом
• Улучшена совместимость с ядрами Linux для новых ОС
• Исправлены проблемы стабильности USB-устройств, особенно для сетевых адаптеров на базе RTL8153 для платформ Raspberry Pi и Tegra Xavier
• Обновлена документация для ESXi-Arm Fling, Raspberry Pi, Ampere Altra, NVIDIA Xavier AGX и NVIDIA Xavier NX (опции доступны в комбобоксе при скачивании продукта)

Загрузить VMware ESXi ARM Edition 1.4 и документацию можно по этой ссылке.

На сайте проекта VMware Labs обновился нативный USB-драйвер для ESXi, который необходим для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Эта версия (1.8) драйверов сделана специально для VMware vSphere 7.0 Update 2. При скачивании драйверов убедитесь, что вы выбрали вариант для нужной версии ESXi:

Что нового появилось в драйверах:

• Полная поддержка ESXi 7.0 Update 2
• По умолчанию отключено сканирование шины USB (расширенная настройка usbBusFullScanOnBootEnabled=0) - это позволяет предотвратить розовый экран смерти (PSOD) для пользователей, использующих несколько сетевых карт на USB-портах

Таблица поддерживаемых чипсетов и адаптеров на сегодняшний день выглядит так:

Загрузить USB Network Native Driver for ESXi для VMware vSphere 7.0 Update 1 и Update 2 можно по этой ссылке.

Аналитический департамент A16Z (они же венчурный фонд Andreesen Horowitz) провели исследование "The Cost of Cloud, a Trillion Dollar Paradox" среди 50 крупных компаний, проанализировав их отчетность и траты на облачную инфраструктуру. Вот эти компании:

Вывод этого исследования интересен - затраты на облака отбирают значительную часть выручки компаний, существенно снижая их маржинальность. Как результат - у этих компаний капитализация занижена на 100 миллиардов долларов (в сравнении с тем, если бы они имели свою инфраструктуру).

Для выбранных 5 сервисов картинка по доле трат на облако в себестоимости сервисов выглядит так:

Уже как пару лет траты организаций на облачную инфраструктуру превышают совокупные траты на железо и софт, и тенденция перехода на публичные и гибридные облака, в целом, сохраняется.

Однако, некоторые организации после внутренних исследований понимают, что на определенном этапе нужно с облаков уходить, так как они просто тянут их вниз с точки зрения затрат, особенно если большая часть операционных затрат компании связана с издержками на облако.

Например, компания Dropbox перешла из облачной инфраструктуры на свое железо и сэкономила $75M за двухлетний период перед IPO (а маржинальность увеличилась с 33% до 67%, что существенно повлияло на капитализацию).

Важным фактором является и оптимизация использования облака (контроль на публичными ресурсами, оптимизация затрат, использование гибридной модели - онпремизной и облачной инфраструктур). Например, компания Segment за счет таких оптимизаций сократила издержки на облака на 30%, при этом за тот же период трафик вырос на 25%.

Самое интересное в переходе на облака то, что на старте это действительно отличный способ не нести капитальных затрат и быстро расти. Но с набором оборотов компании становится понятно, что издержки на облачные сервисы тянут ее вниз, и она не добирает маржу, которую могла бы иметь, используя собственную инфраструктуру. Но уже поздно - развертывание собственной инфраструктуры для средней и крупной организации большой проект - который, зачастую, бизнес не может позволить себе ни по деньгам, ни по времени.

В общем, вывод этого исследования таков - в облаках стартовать можно и нужно, но если вы хотите выжимать максимум из своего бизнеса, то можно сделать и свою инфраструктуру, предварительно все посчитав, конечно же. Надо понимать, что не всегда на своем железе будет дешевле - все зависит от специфики бизнеса, модели, технических требований и многого другого.

Это гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины в аренду по модели IaaS. В рамках плана по поддержке ИТ-отрасли в России власти хотят запретить государственным структурам строить новые собственные дата-центры за счет бюджета — вместо этого им предложат пользоваться услугами cloud-провайдеров и коммерческих ЦОД.

Сегодня заказчики из госсектора для удовлетворения потребностей в ИТ-ресурсах, как правило, строят собственные небольшие дата-центры и частные облака. Однако степень их надежности не всегда удовлетворяет требованиям, а капитальные затраты на строительство и эксплуатацию создают дополнительную нагрузку на бюджет.

В рамках новой инициативы для решения этой проблемы предлагается обязать различные структуры и ведомства пользоваться сервисами российских провайдеров облачных услуг. Если инициативу примут, строить новые ЦОД не смогут и региональные органы исполнительной власти. Новое предложение также предполагает перевод ГИС в коммерческие дата-центры.

Кроме повышения эффективности реализации бюджета, это позволит поддержать российский провайдеров облачных сервисов и коммерческие ЦОДы, простимулировав спрос на их услуги, на что и нацелена глобальная инициатива правительства по содействию отечественному ИТ.

Нужна надежная и защищенная виртуальная инфраструктура? Публичные, частные и гибридные облака, Облако ФЗ-152, PCI DSS хостинг, решения для систем SAP — арендуйте сервисы от проверенного облачного провайдера на нашем сайте.

Мы несколько раз писали об онлайн-сервисе VMware vSphere DRS Dump Insight, который позволяет показывать различную информацию по перемещению виртуальных машин в кластере DRS на портале самообслуживания, куда пользователи могут загружать файлы дампов.

Это позволяет вам получить ответы на следующие вопросы:

• Какие рекомендации DRS сделал на основе анализа cost/benefit
• Почему DRS сделал именно эту рекомендацию
• Почему DRS вообще иногда не делает рекомендаци для балансировки кластера
• Как кастомное правило affinity/anti-affinity влияет на балансировку в кластере
• Где взять полный список рекомендаций DRS

На днях у VMware вышло руководство пользователя по этой утилите, которое будет интересно почитать всем администраторам кластеров VMware DRS, решившим начать анализировать дампы DRS:

DRS Dump Insight User Guide небольшой и занимает всего 20 страниц, но там есть очень конкретные рекомендации по работе с интерфейсом утилиты и по трактовке ее результатов:

Напомним, что DRS Dump Insight в целом может делать следующие вещи:

• Автоматизация воспроизведения дампов (с помощью встроенных кастомных DRS replayers)
• Предоставление и визуализация дополнительной информации, которая недоступна в обычных анализаторах логов
• Парсинг и анализ логов для понимания и наглядного отображения решений балансировщика DRS
• Генерация итогового результата в текстовом формате

Скачать VMware vSphere DRS Dump Insight User Guide можно по этой ссылке.

Недавно мы рассказывали про новую возможность KB Insights, которая появилась в решении VMware vRealize Log Insight Cloud. На днях VMware объявила о выпуске еще одного обновления этого облачного продукта для аналитики лог-файлов и мониторинга инфраструктуры.

Одной из новых возможностей июньского релиза Log Insight Cloud стала возможность Live Tail для логов, в которых вы ищете источники проблем. Этот механизм позволяет в реальном времени "прицепиться" к файлам журнала, например, определенного хоста и отслеживать там нужные вам параметры.

На примере ниже коллеги из VMware разбирают эту функциональность. Допустим, у вас возникла проблема с одним из веб-серверов, который дает необычные всплески трафика, и вы хотите понять, почему. С помощью Live Tail можно понять, какой IP-адрес соединяется с сервером и отследить, что происходит с трафиком данного приложения:

Тут рабочий процесс может выглядеть следующим образом:

• Добавляем ключевое слово, например, имя вебсайта
• Добавляем log_type для сужения области отслеживания, в данном случае Apache
• Добавляем фильтр, чтобы убедиться, что мы отслеживаем только те логи, где есть поле remote_host
• Добавляем колонку remote_host, чтобы видеть в реальном потоке, с какими хостами происходят соединения

Перейти в представление Live Tail можно по кнопке в правом верхнем углу раздела Export Logs:

Любой запрос можно добавить в Избранное (создать Favorite Query), после чего его можно выбирать для отслеживания в режиме Live Tail:

Для фильтрации можно использовать составные фильтры по множеству условий:

Ключевое слово подсвечивается в самом логе:

Live stream можно останавливать и запускать снова, а элементы лога можно развернуть, чтобы посмотреть детали записи:

Отображаемые колонки можно добавлять и удалять:

Также есть ролевая модель доступа, то есть теперь, например, вы можете дать права администраторам приложений с ограничениями, чтобы они сами разбирались в своих проблемах:

Помимо функций Live Tail, в июньском релизе были также добавлены новые дэшборды и запросы для AWS и Azure.

Так теперь выглядят новые интеграции для AWS:

Например, вот дэшборд EventBridge Overview:

А вот все дэшборды для EventBridge:

Ну а вот так выглядят новые интеграции для Azure:

Если вы хотите попробовать поработать с VMware vRealize Log Insight в облаке AWS или Azure, то VMware предоставляет пробную версию на 30 дней.

Некоторые администраторы VMware vSphere хотели бы закрыть доступ для некоторых пользователей к интерфейсу vSphere Client или ограничить его определенными адресами, оставив доступ через API. Например, это нужно тогда, когда пользователи vSphere не соблюдают установленные процедуры и регламенты при работе в интерфейсе клиента (например, не фиксируют внесенные в конфигурации виртуальных машин изменения).

Вильям Ламм рассказал о простом способе ограничения доступа к UI клиента vSphere Client. Делается это через настройки сервера Apache Tomcat, на базе которого построен виртуальный модуль vCenter Server Appliance. Называется это Access Control Valve - по ссылке можно подробно изучить опции, которые можно применять, а мы же рассмотрим простой пример ниже.

Идем по SSH на vCSA и открываем там следующий файл:

/usr/lib/vmware-vsphere-ui/server/conf/context.xml 

В него добавляем следующую запись:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost|x.x.x.x|y.y.y.y"/>

Значения x.x.x.x, y.y.y.y и далее за ними можно указать как разрешенные адреса для соединения с сервером. Блок "127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost" должен присутствовать всегда для обеспечения локального соединения сервисов самого vCenter.

Адреса, не занесенные в этот список, при соединении через веб-браузер получат 403 ошибку, при этом доступ через PowerCLI и API останется для этих адресов (поскольку это только настройка веб-сервера):

Да, и надо не забыть, что для того, чтобы изменения веб-сервера вступили в силу, надо его перезапустить командой:

service-control --restart vsphere-ui

Компания VMware рассказала о том, что поменяется в содержательной части главного события года в сфере виртуализации в этом году - конференции VMworld 2021, которая пройдет 5-7 октября этого года. Перед этим мероприятием VMware получила около 1500 заявок на выступления и доклады от всех участников своей экосистемы (заказчики, партнеры, технические специалисты и блоггеры).

Теперь при формировании контентной части события организаторы будут придерживаться следующих принципов:

• Основной фокус будет сделан на заказчиках VMware, которые могут поделиться примерами использования продуктов и технологий из реальной жизни.
• Будет больше экспертных сессий с глубоко техническим контентом, для которых предусмотрен специальный билет Tech+. Он позволит больше общаться с экспертами и иметь доступ к документам уровня "deep dive".
• Бизнес и технические сессии будут разделяться по уровням сложности 100 и 200, также будут специальные технические сессии повышенной сложности с уровнем T300.
• Вернутся технические сессии, касающиеся VMware Design Studio и VMware {code} - об этом просили многие участники.
• Сессии можно будет также искать по метатемам, таким как управление несколькими облаками, защита современных приложений и облачных сервисов, использование перспективных технологий и т.п.

Не обойдется и без таких тем, как diversity, equity, inclusion и sustainability (хотя не очень понятно, как они относятся именно к виртуализации - но, видимо, у VMware уже есть и какая-то социальная миссия).

Регистрация на VMworld 2021 будет открыта с 15 июня по этой ссылке. Кстати, интересно, что прошлый VMworld Online посетили боле 100 тысяч участников.

Новость от нашего партнера - компании ИТ-ГРАД, предоставляющей в аренду виртуальные машины VMware из облака по модели IaaS.

Спешим поделиться важными новостями. Наряду с брендом «ИТ-ГРАД» на всех наших площадках в социальных сетях будет использоваться бренд #CloudMTS — с начала июня публикации на корпоративных ресурсах продолжатся от его имени.

Объединенная техническая команда облачных провайдеров готова еще активнее делиться накопленным опытом, экспертизой и ИТ-инсайтами. Это значит, что наши социальные сети, блоги и рассылки станут еще интереснее и полезнее. А экспертного контента, отраслевых активностей, акций и спецпредложений будет еще больше. Читайте нас, рекомендуйте коллегам и друзьям!

• Facebook
• Vkontakte
• Twitter
• Telegram
• Zen.yandex
• LinkedIn
• Habrahabr
• YouTube

Подробнее на сайте компании ИТ-ГРАД.

Многие Enterprise-администраторы настраивают автоматический регулярный бэкап решения для виртуализации и агрегации сетей VMware NSX-T из консоли, что описано, например, вот тут.

Между тем, как правильно заметил автор virten.net, при неудачном завершении задачи резервного копирования администратор не получает нотификации даже в дэшборде в разделе алармов.

В случае падения задачи бэкапа информация об этом доступна только в разделе Backup & Restore настроек:

Эту информацию можно получить и через API:

> GET /api/v1/cluster/backups/history HTTP/1.1
{
  "cluster_backup_statuses": [
    {
      "backup_id": "5cf21742-091a-b9b9-1f24-ad75ede2d23b-1615489436",
      "start_time": 1615489436085,
      "end_time": 1615489440865,
      "success": false,
      "error_code": "BACKUP_AUTHENTICATION_FAILURE",
      "error_message": "either backup server login failed or unauthorized access to backup directory"
    }
  ],
  "node_backup_statuses": [
    {
      "backup_id": "5cf21742-091a-b9b9-1f24-ad75ede2d23b-1615403036",
      "start_time": 1615403036017,
      "end_time": 1615403354709,
      "success": true
    }
  ],
  "inventory_backup_statuses": [
    {
      "backup_id": "inventory-1615490636",
      "start_time": 1615490636254,
      "end_time": 1615490641758,
      "success": true
    }
  ]
}

В данном примере неудачно завершился процесс резервного копирования кластера, поэтому нужно смотреть не только на статусы узлов (кстати, времена указаны в миллисекундах).

Коллега с virten.net написал сценарий на Python для Nagios, который позволит вам проверить статус последнего бэкапа кластера NSX-T, а также посмотреть возраст последней имеющейся резервной копии:

usage: check_nsxt_backup.py [-h] -n NSX_HOST [-t TCP_PORT] -u USER -p PASSWORD
                            [-i] [-a MAX_AGE]

# python check_nsxt_backup.py -n nsx.virten.lab -u audit -p password
NSX-T cluster backup failed
NSX-T node backup is to old (1461 minutes)

На сайте Вильяма Лама есть специальный раздел, посвященный вложенной виртуализации (Nested Virtualization) на базе гипервизора VMware ESXi. В частности, Вильям делает сборки ESXi, которые уже подготовлены к использованию в качестве виртуальных машин как виртуальные модули (Virtual Appliances) в формате OVA. Это может понадобиться для тестовых сред, когда вам нужно развернуть большую инфраструктуру и сделать полноценный кластер, а в распоряжении есть только 1-2 физических сервера.

Также обратите внимание на наш пост о библиотеке Content Library с шаблонами виртуальных модулей Nested ESXi от Вильяма. Адрес для подписки на эту библиотеку следующий:

https://download3.vmware.com/software/vmw-tools/lib.json

Кстати, все статьи о вложенной виртуализации можно найти и у нас по тегу Nested.

Если вы часто имеете дело с технической поддержкой VMware, то знаете, что довольно часто требуется собирать с хостов VMware ESXi дампы. Нередко администраторы настраивают удаленную отсылку дампов на сервер VMware vCenter Server Appliance (vCSA). По умолчанию размер раздел для дампов на нем равен 2 ГБ, что может оказаться мало, если инфраструктура у вас большая.

Вильям Лам задался этим вопросом и вспомнил, что есть такая настройка Repository max size в разделе ESXi Dump Collector для старого клиента vSphere Web Client:

Между тем, в новый vSphere Client на базе HTML 5 эту настройку не перенесли. Поэтому если вы используете VMware vCSA версий 6.7 или 7.0 с новым клиентом, то вам нужно открыть файл /etc/sysconfig/netdumper и изменить там следующий параметр:

NETDUMPER_DIR_MAX_GB 

Максимальный его размер может составлять 10GB.

После изменения размера раздела для дампов нужно перезапустить сервис дампера. На vCSA 7 делается одной командой:

service-control --restart vmware-netdumper

На vCSA 6.7 двумя:

service-control --stop vmware-netdumper
service-control --start vmware-netdumper

В 2014 году мы писали о продукте Horizon View Event Notifier, который предназначен для отправки администраторам писем по протоколу SMTP с различными алертами, произошедшими в VMware View.

Утилита соединяется с одной или несколькими базами данных Horizon View Event Database, вытаскивает оттуда выбранные администратором события (ошибки, предупреждения, инфо) и шлет письма на указанный email-адрес. При этом поддерживается возможность работы с несколькими БД, что позволяет собирать алерты с разных инсталляций VMware View (они же View Pods).

Спустя 7 лет, на сайте проекта VMware Labs неожиданно вышло обновление этой утилиты - появился Horizon Event Notifier 1.5. Что там нового:

• Изменено название с Horizon View Event Notifier на Horizon Event Notifier
• Изменена иконка и некоторые графические ресурсы
• Нотификации приходят в локальном формате времени, где запущена утилита
• Алерты теперь видны в интерфейсе
• Совместимо и протестировано с VMware Horizon 2103 (вышел в марте этого года)

Скачать VMware Horizon Event Notifier 1.5 можно по этой ссылке.

Некоторое время назад мы писали о новой версии решения VMware Cloud Foundation 4.2 (VCF), которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. 

На днях VMware сделала небольшое обновление этого пакета - VMware Cloud Foundation 4.2.1, давайте посмотрим, что там нового:

• Обновления безопасности для Photon OS в SDDC Manager 4.2.1 (пакет PHSA-2021-3.0-185 обновлен до PHSA-2021-3.0-209 - подробнее тут).
• Критические обновления безопасности для VMware vCenter Server Appliance (мы писали об уязвимости тут).
• Обновление некоторых версий продуктов в составе пакета.

Новый Bill of Materials включает в себя следующие версии решений VMware:

Для пользователей пакета версии 3.10.2 также есть обновление - VCF 3.10.2.1, о нем прдробно рассказано вот тут. Вот его Bill of Materials:

Об обновлении подсистемы безопасности VMware vCenter Server Appliance 6.7 Update 3n рассказано тут.

Вильям Ламм написал интересную статью про USB-устройства на хосте VMware ESXi, когда нужно использовать некоторые устройства как хранилища, а некоторые - для проброса в виртуальные машины. При этом, в рамках данной методики, не нужно останавливать USB Arbitrator Service на хосте.

Итак, для начала выводим список доступных USB-интерфейсов на сервере:

esxcli hardware usb passthrough device list

У Вильяма в списке 2 USB-хранилища (их пары VendorId:ProductId имеют значения 90c:2000 и 90c:1000):

Для второго устройства можно отключить именно функции проброса USB (passthrough), чтобы устройство не могло быть презентовано виртуальной машине. Для этого выполняем такую команду:

esxcli hardware usb passthrough device disable -d 2:7:90c:1000

После этого будет вот такая картина:

Далее уже можно подключить это устройство хранения к хосту ESXi, чтобы использовать его для создания VMFS-томов. Процедура описана вот тут, посмотрим на нее вкратце.

Сначала добавляем расширенную настройку (Advanced Setting) на хосте ESXi, чтобы он принимал SSD-диски, подключенные к USB:

esxcli system settings advanced set -o /Disk/AllowUsbClaimedAsSSD -i 1

Теперь нужно создать SATP-правило, которое помечает наше USB-устройство как SSD-диск. Для этого нужно получить имя устройства с помощью команды:

vdq -q

Затем создаем переменную с именем устройства, например:

DEVICE_NAME="t10.JMicron_Generic_________0123456789ABCDEF"

Затем выполняем следующие команды для создания SATP-правила и перезагрузки устройства, которое подцепится как SSD-хранилище:

esxcli storage nmp satp rule add -s VMW_SATP_LOCAL --device=${DEVICE_NAME} --option=enable_ssd

esxcli storage core claiming unclaim --type device --device=${DEVICE_NAME}

esxcli storage core claimrule load

esxcli storage core claimrule run

Теперь устройство можно использовать как SSD-диск для vSAN или VMFS. Если хотите использовать его для vSAN, то нужно включить соответствующую расширенную настройку командой:

esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1

После этого вы сможете увидеть данное устройство в выводе команды vdq -q как совместимое для vSAN, на котором можно создавать дисковые группы:

Если же вы хотите использовать этот SSD-диск как хранилище VMFS, то нужно сначала создать том, чтобы он был виден в интерфейсе vSphere Client.

Создаем переменную с полным путем к устройству:

DEVICE_PATH="/vmfs/devices/disks/t10.JMicron_Generic_________0123456789ABCDEF"

Далее выполняем команду, которая разметит наш том как VMFS:

partedUtil mklabel ${DEVICE_PATH} msdos

END_SECTOR=$(eval expr $(partedUtil getptbl ${DEVICE_PATH} | tail -1 | awk '{print $1 " \\* " $2 " \\* " $3}') - 1)

/sbin/partedUtil "setptbl" "${DEVICE_PATH}" "gpt" "1 2048 ${END_SECTOR} AA31E02A400F11DB9590000C2911D1B8 0"

/sbin/vmkfstools -C vmfs6 -b 1m -S $(hostname -s)-local-usb-ssd-datastore ${DEVICE_PATH}:1

Если все в порядке, вы увидите новый том в списке VMFS-томов в vSphere Client: